Via: UK.AC.EARN-RELAY; 16 OCT 89 11:45:47 GMT Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 1761; Sun, 15 Oct 89 05:28:38 BS Received: from CEARN.cern.ch by UKACRL.BITNET (Mailer X1.25) with BSMTP id 0454; Sun, 15 Oct 89 05:28:36 B Received: by CEARN (Mailer R2.03B) id 8655; Sun, 15 Oct 89 05:28:30 GVA Date: Sat, 14 Oct 89 15:00:10 MDT Reply-To: INFO-ATARI16@MIL.ARMY.WSMR-SIMTEL20 Sender: INFO-ATARI16 Discussion Comments: Warning -- original Sender: tag was INFO-A16@MARIST From: INFO-ATARI16-REQUEST@MIL.ARMY.WSMR-SIMTEL20 Subject: INFO-ATARI16 Digest V89 #521 Comments: To: INFO-ATARI16@WSMR-SIMTEL20.ARMY.MIL INFO-ATARI16 Digest Sat, 14 Oct 89 Volume 89 : Issue 521 Today's Topics: 1040 ST for sale 520STFM FOR SALE (w/many xtras) Event multi Laser C and TOS 1.4 Laser C bugs TOS 1.4, memory chips, T16...and the Mega2 STs Wanted: Info on DEGAS picture compression ---------------------------------------------------------------------- Date: 13 Oct 89 05:28:56 GMT From: att!drutx!druks!jamesc@ucbvax.Berkeley.EDU (CochraneJT) Subject: 1040 ST for sale I have a 1040 ST that I no longer need since I'm now using a Mega 2. It's in good condition, runs fine and has been very reliable. It includes the standard double sided drive and 1 meg memory, but no monitor. I would like $400 for it. If you are interested or have questions about it, I can be reached at home (most) weekday nights and on weekends at 303-449-3315 or, if you prefer, you can send me e-mail. Jim Cochrane jamesc@druks.ATT.COM att!druks!jamesc ------------------------------ Date: 14 Oct 89 20:21:58 GMT From: gem.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!geoffs@tu t.cis.ohio-state.edu (Geoffrey Sauerborn ) Subject: 520STFM FOR SALE (w/many xtras) FOR SALE: Color Atari 520STFM SYSTEM w/RAM board upgrade. (also w/PC DITTO and 5 1/4" floppy!) (software and over 50 disks!) $600 plus shipping. Atari 520STFM system includes:. Color monitor (SC1224). EZRAM II board - 1 to 2.5 meg RAM upgrade. Late model (only 2 years old)-(Rev.H) includes Television RF output. External SS 400K SF354 3 1/2" floppy disk drive. *NEW External DS/DD 360K I.B. DRIVE 5 1/4" floppy disk drive.* TOS in ROM, Atari Basic, DR Logo., and of course GEM in ROM & mouse. Lots of software Utilities: *PC DITTO* PRINTMASTER PLUS HIPPO WORD ST LEDGER Original Atari Development System Documentation & Utilities. (plus C Compiler updated to ver 4.14 1986). GAMES FLIGHT SIMULATOR II (Plus east coast Scenery Disk 7). HARRIER STRIKE MISSION (needs $5 disk replacement). I will through in: OVER 50 disks!!! PD or Shareware software. Archived and indexed. includes: UNITERM(using now),MICROEMACS 3.91/4,Compilers,Drawing...more. HACK,LARN,RISK,MONOWARE,WHEEL OF FORTUNE,... too many to name. 3 Flip File dust cover 3.5 disk storage containers. 16 256K DRAM chips (enough for 1meg upgrade). [ Some of these chips are flakey so they are not included with the RAM board. I don't have a chip tester to pick out the bad ones. Maybe it can be done in software? ] All items shipped in original boxes with manuals. -- ---> geoffs@brl.arpa -or- geoffs@smoke.brl.mil -- ------------------------------ Date: 14 Oct 89 09:10:54 GMT From: agate!stew.ssl.berkeley.edu!ericco@ucbvax.Berkeley.EDU (Eric C. Olson) Subject: Event multi Once again I'm trying to make GEM AES do something useful. Its now quite late, and the situation looks grim ... Is it possible to check the state of EITHER mouse button using event_multi? Or any other (documented) routine? I have found that specifying 0x3 for the bstate parameter and 0x3 for the bmask parameter only matchs button chords. How do I tell event_multi to wait for a left OR a right mouse click (or both)? Thanks in advance, Eric Eric ericco@ssl.berkeley.edu ------------------------------ Date: 14 Oct 89 02:51:14 GMT From: gem.mps.ohio-state.edu!ginosko!shadooby!mailrus!jarvis.csri.toronto.edu!utgpu!w atmath!julian!uwovax!7103_300@tut.cis.ohio-state.edu Subject: Laser C and TOS 1.4 In article <8028@microsoft.UUCP>, w-darekm@microsoft.UUCP (Darek Mihocka) writes: > [ some very accurate comments on Laser ] > ... I just > stick to assembler for now while somebody writes a decent C compiler for > the ST. I agree with you on Laser; it had promise, but the buggy code generation, incomplete library, and weird disk cache eventually caused me to give up on it. Fortunately, there is an alternative; the GNU C Compiler. It's a huge memory pig (you really need 2 megabytes to run it) but it produces very good code, is ANSI compatible, and now comes with an (almost) ANSI and Unix compatible library. And the price is right... it's free! (Source is available too, and it's being actively supported by the Free Software Foundation). The current version is 1.36, available from dsrgsun.ces.cwru.edu and (I think) terminator. -- Eric Smith ersmith@uwovax.uwo.ca ersmith@uwovax.bitnet ------------------------------ Date: 14 Oct 89 08:43:52 GMT From: ubc-cs!grads.cs.ubc.ca!horsch@beaver.cs.washington.edu (Michael Horsch) Subject: Laser C bugs In article <8044@microsoft.UUCP> w-darekm@microsoft.UUCP (Darek Mihocka) writes: [some gripes about Laser C... The ones I am addressing are not edited out (how's that for being contrapositive!)] > The C code generation has some problems when you get >pointers to structures containing pointers, etc. I have never had this one, and I've been messing around a lot with objects, and structures which contain pointers to objects, and linked lists of trees whose nodes point to objects, and... > What also irritates >me is that if you have a string constant and you forget to put in the >closing quotation marks, it crashes. Not this either. I always forget to close qoutes. Sometimes I forget the difference between " and '. I only get compiler errors. > All of these bugs have been present >since Megamax C, I keep reporting them, and they keep ignoring them or >telling me they're fixed. That's pissing me off to no end, because otherwise >I like the package a lot. Keep reporting them. I would too, if I found any. But mostly I find my own bugs. No implication implied. > >The disk cache tends to mess up when you are low on RAM and compiling a >large program (i.e. more than one module or more than a "hello world" >skeleton). I assume the parenthetical remark to be slightly sarcastic, but your argument about low RAM behaviour makes sense to me (I have a Mega2, so this is never a problem). I agree with an earlier posting in which you suggested that the cache be optional. >Sure the cache is great if you're compiling off floppy, but you're not going >to develop a large project on floppy. Why not? The disk cache and RAM resident tools make this completely reasonable. A little painful at the start of a programming session (and after unrecoverable errors), for sure, but certainly not completely unthinkable. Especially for those (i.e. me) who (perhaps) misguidedly purchased a machine with more RAM instead of a hard disk. I am not a real C programmer, that is, I don't spend months working on real projects (in fact, I'm a Prolog hacker `by trade' :-) and my Mega2 is somewhat ignobly reduced to a real slow terminal for most of its use) so I consider one-floppy development adequate for my medium sized hacks ---but only with the cache, etc. > >- Darek Mike ("By trade?" --Well, it beats working for a living!) -- Michael C. Horsch Disclaimer: I'm not thinking for anyone else but horsch@cs.ubc.ca me; I'm having enough trouble as it is! Dept. of Computer Science University of British Columbia -- If you don't waste time with your friends, you're just wasting your time. -- ------------------------------ Date: 14 OCT 89 11:32:06 CST From: Z4648252 Subject: TOS 1.4, memory chips, T16...and the Mega2 STs Can anyone shed some light preparing a Mega2 ST that has six ROM sockets for use with the T16 and upgrading the Mega2's memory to four meg? I've been reading conflicting data about what brand and speed memory chips to use if one wants to use the T16. I've also been reading that the T16 is happier if used with fast ROM, that is, copying the original TOS 1.4 EPROM into faster EPROM chips. Also, should the older 'Atari' blitter be replaced with the newer? Incidentally, the 74LS373 chips have been replaced. I had problems with Spectre until they were. SIGH...this is a terribly worded letter. Basically, I'm only asking: 1. What memory chips should be used for upgrading the ST2 to a ST4 if used with the T16? 2. Should the chipped TOS 1.4 be transferred to fast EPROMS to gain maximum results from the T16? 3. Should the Atari blitter be replaced with the newer? 4. Yes, the 74LS373 chips have been replaced. Larry Rymal: |East Texas Atari 68NNNers| ------------------------------ Date: 14 Oct 89 20:00:49 GMT From: pasteur!cory.Berkeley.EDU!jlemon@ucbvax.Berkeley.EDU (Jonathan Lemon) Subject: Wanted: Info on DEGAS picture compression In article <23086@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes: >Wayne Schellekens asks: > >>Does anyone have any information as to how DEGAS compresses its >>picture files? > >His file "ST Picture Formats" may be available on the ST archives, or I know >it's available on CompuServe.. (since I uploaded it there) > Also right here. ST Picture Formats ------------------ Compiled by: Dave Baggett (arpanet: dmb@TIS.COM) (Please report errors or additions) CONTRIBUTORS Phil Blanchfield David Brooks Neil Forsyth Ken MacLeod Darek Mihocka George Seto Joe Smith Greg Wageman Gerry Wheeler Introductory information ------------------------ word = 2 bytes long = 4 bytes palette = Hardware color palette, stored as 16 words. First word is color register zero (background), last word is color register 15. Each word has the form: Bit: (MSB) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 (LSB) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 0 0 0 0 0 R2 R1 R0 0 G2 G1 G0 0 B2 B1 B0 R2 = MSB of red intensity R0 = LSB of red intensity G2 = MSB of green intensity G0 = LSB of green intensity B2 = MSB of blue intensity B0 = LSB of blue intensity Intensity ranges from 0 (color not present) to 7 (highest intensity). Example: ? red = 7, green = 3, blue = 5 ? -> 0735 (hex) Caveat: It is wise to mask off the upper four bits of each palette entry, since a few programs store special information there (most notably Art Studio). The Formats ----------- 1 long resolution (0 = low res, 1 = medium res, 2 = high res) 16 words palette 12 bytes filename (" . ") 1 byte Left color animation limit (starting color number) 1 byte Right color animation limit (ending color number) 1 byte color rotation speed 1 byte color rotation direction 1 word color rotation duration (number of iterations) 18 longs reserved for expansion 16000 words picture data (screen memory) ----------- 32128 bytes total NOTE: To get this feature on versions 0.9 and later select the Grabber icon and click the right mouse button in the eye of the second R in the word GRABBER. 1 long magic number BABEEBEA (hex) (seems to be ignored) 1 word width of sprite in bytes (always divisible by 8) 1 word height of sprite in scan lines 1 word size of sprite in bytes + 10 (!) 1 word x coordinate of sprite (must be divisible by 16) - 1 1 word y coordinate of sprite - 1 1 word number of frames 1 word animation speed (larger means slower) 1 long reserved; should be zero -------- 44 bytes total for header ? words sprite image data (words of screen memory) for each sprite, in order 1 word resolution (0 = low res, 1 = medium res, 2 = high res) Other bits may be used in the future; use a simple bit test rather than checking for specific word values. 16 words palette 16000 words picture data (screen memory) ----------- 32034 bytes total 1 word resolution (0 = low res, 1 = medium res, 2 = high res) Other bits may be used in the future; use a simple bit test rather than checking for specific word values. 16 words palette 16000 words picture data (screen memory) 4 words left color animtion limit table (starting color numbers) 4 words right color animation limit table (ending color numbers) 4 words animation channel direction flag (0 = left, 1 = off, 2 = right) 4 words animation channel delay in 1/60's of a second. [0 - 128] ----------- 32066 bytes total 1 word resolution (same as Degas, but high order bit is set; i.e., hex 8000 = low res, hex 8001 = medium res, hex 8002 = high res). Other bits may be used in the future; use a simple bit test rather than checking for specific word values. 16 words palette < 32000 bytes control bytes 4 words left color animtion limit table (starting color numbers) 4 words right color animation limit table (ending color numbers) 4 words animation channel direction flag (0 = left, 1 = off, 2 = right) 4 words animation channel delay in 1/60's of a second. [0 - 128] ----------- < 32066 bytes total Control byte meanings: For a given control byte, x: 0 <= x <= 127 Use the next x + 1 bytes literally (no repetition) -127 <= x <= -1 Use the next byte -x + 1 times -128 No operation (ignore) Compression Scheme: Each scan line is compressed separately; i.e., all data for a given scan line appears before any data for the next scan line. The scan lines are specified from top to bottom (i.e., 0 is first). For each scan line, all the data for a given bit plane appears before any data for the next higher order bit plane. To clarify: The first data in the file will be the data for the lowest order bit plane of scan line zero, followed by the data for the next higher order bit plane of scan line zero, etc., until all bit planes have been specified for scan line zero. The next data in the file will be the data for the lowest order bit plane of scan line one, followed by the data for the next higher order bit plane of scan line one, etc., until all bit planes have been specified for all scan lines. 16000 words picture data (screen memory) (palettes are stored in separate files) ----------- 32000 bytes total 1 byte resolution (same as NEO, but +3 indicates rotation information also follows) If resolution > 2 ? 1 byte left and right color animation limits. High 4 bits hold left (start) limit; low 4 bits hold right (end) limit 1 byte direction and speed of color animation (negative value indicates left, positive indicates right, absolute value is delay in 1/60's of a second. 1 word color rotation duration (number of iterations) ? 1 word number of control bytes 1 word number of data bytes 16 words palette 3-10667 bytes control bytes 2-32000 bytes data bytes ------------- 42-32044 bytes total Control byte meanings: For a given control byte, x: x < 0 Absolute value specifies the number of unique words to take from the data section (from 1 to 127) x = 0 1 long is taken from the control section which specifies the number of times to repeat the next data word (from 128 to 32767) x = 1 1 word is taken from the control section which specifies the number of unique words to be taken from the data section (from 128 - 32767) x > 1 Specifies the number of times to repeat the next word taken from the data section (from 2 to 127) 80 words first scan line of picture (unused) -- should be zeroes 15920 words picture data (screen memory) for scan lines 1 through 199 9552 words 3 palettes for each scan line (the top scan line is not included because Spectrum 512 can't display it) ----------- 51104 bytes total 1 word 5350 (hex) ("SP") 1 word 0 (reserved for future use) 1 long length of data bit map 1 long length of color bit map <= 32092 bytes compressed data bit map <= 17910 bytes compressed color bit map -------------- < 50014 bytes total Data compression: Compression is via a modified run length encoding (RLE) scheme. The data map is stored as a sequence of records. Each record consists of a header byte followed by one or more data bytes. The meaning of the header byte is as follows: For a given header byte, x: 0 <= x < 127 Use the next x + 1 bytes literally (no repetition) -128 <= x < 0 Use the next byte -x + 2 times The data appears in the following order: 1. Picture data, bit plane 0, scan lines 1 - 199 2. Picture data, bit plane 1, scan lines 1 - 199 3. Picture data, bit plane 2, scan lines 1 - 199 4. Picture data, bit plane 3, scan lines 1 - 199 Decompression of data ends when 31840 data bytes have been used. Color map compression: Each 16-word palette is compressed separately. There are three palettes for each scan line (597 total). The color map is stored as a sequence of records. Each record starts with a 1-word bit vector which specifies which of the 16 palette entries are included in the data following the bit vector (1 = included, 0 = not included; i.e., stays the same). The least significant bit of the bit vector refers to palette entry zero, while the most significant bit refers to palette entry 15. Bit 15 must be zero, since Spectrum 512 does not use palette entry 15. Bit 0 should also be zero, since Spectrum 512 always makes the background color black. The words specifying the values for the palette entries indicated in the bit vector follow the bit vector itself, in order (0 - 15). 1 word number of frames 16 words palette 1 word speed (0 - 99; higher value is faster) 1 word direction (0 = forwards, 1 = backwards) 1 word end action (what to do after the last frame) 0 = pause, then repeat from beginning 1 = immediately repeat from beginning 2 = reverse 1 word width of film in pixels 1 word height of film in pixels 1 word version number (major) 1 word version number (minor) 1 long magic number 27182818 (hex) 3 longs reserved (should be all zeros) -------- 32 words total for header ? words image data (words of screen memory) for each frame, in order header ? 1 long version number (if zero, entire header is ignored) 38 * 2 longs pattern data (anyone know how to use this?) 51 longs reserved ? < 51200 bytes compressed bitmap data ------------- < 51716 bytes total Bitmap compression: The bitmap data is for a 576 pixel by 720 pixel image. The data is stored as a sequence of records. Each record consists of a control byte followed by one or more data bytes. The meaning of the control byte is as follows: For a given control byte, x: 0 < x < 127 Use the next x + 1 bytes literally (no repetition) -128 <= x <= 0 Use the next byte -x + 1 times There are 72 bytes per scan line. Each bit represents one pixel; 0 = white, 1 = black. Version of Fri Sep 2 01:31:21 EDT 1988 ---------------------------- >8 ------------------------------------- -- Jonathan ...ucbvax!cory!jlemon or jlemon@cory.Berkeley.EDU ------------------------------ End of INFO-ATARI16 Digest V89 Issue #521 *****************************************